1. Field of the Invention
This invention relates to computer networks, and more specifically, to a network protocol proxy.
2. Background Information
Computer networks typically comprise a plurality of interconnected entities. An entity may consist of any device, such as a computer or end station, that “sources” (i.e., transmits) or “sinks” (i.e., receives) datagrams (e.g., packets and/or frames). A common type of computer network is a local area network (“LAN”) which typically refers to a privately owned network within a single building or campus. LANs typically employ a data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack). In many instances, several LANs may be interconnected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a wide area network (“WAN”) or intranet that may span an entire country or continent.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “bridging” function between two or more LANs. Alternatively, a switch may be utilized to provide a “switching” function for transferring information between a plurality of LANs or end stations. Bridges and switches may operate at various levels of the communication protocol stack. For example, a switch may operate at layer 2 which, in the Open Systems Interconnection (OSI) Reference Model, is called the data link layer and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers. Data frames at the data link layer typically include a header containing the MAC address of the entity sourcing the message, referred to as the source address, and the MAC address of the entity to whom the message is being sent, referred to as the destination address. To perform the switching function, layer 2 switches examine the MAC destination address of each data frame received on a source port. The frame is then switched onto the destination port(s) associated with that MAC destination address.
Other network devices, commonly referred to as routers, may operate at higher communication layers, such as layer 3 of the OSI Reference Model, which in TCP/IP networks corresponds to the Internet Protocol (IP) layer. Data frames at the IP layer also include a header which contains an IP source address and an IP destination address. Routers or layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g. token ring). Thus, layer 3 devices are often used to interconnect dissimilar subnetworks.
Multimedia Applications
Increasingly, computer networks are being called upon to support time-sensitive traffic, such as the transmission of audio and/or video files in real-time. More specifically, technology has recently been developed to support streaming multimedia applications. With streaming, a user can begin playing or listening to the corresponding content as it is being received at his or her computer. That is, the user does not have to wait until the entire file is downloaded before playing the content as was previously the case. Sources of data for streaming can include both live feeds, such as videoconferences, concerts, etc., and stored clips or files.
To support streaming multimedia traffic, a number of real-time oriented network protocols have been developed and/or proposed. The Real-time Transport Protocol (RTP), for example, provides end-to-end delivery services to support applications transmitting real-time data. RTP typically runs on top of the User Datagram Protocol (UDP) to utilize its multiplexing and checksum services, although other transport protocols besides UDP may also be used. RTP is a proposed standard from a working group of the Internet Engineering Task Force (IETF), which is an independent standards organization, and is described at Request for Comments (RFC) 1889. RTP defines several messages that specify the type of audio encoding being used, e.g., pulse code modulation (PCM). RTP messages also contain timestamps and sequence numbers which are used by a receiver to reconstruct the timing produced by the source.
The Real-Time Control Protocol (RTCP) works in conjunction with RTP, and is responsible for the management of the real-time session between the source and the receiver. During an RTP session, RTCP reports are periodically sent back-and-forth between the receiver and the source. These reports provide feedback regarding reception quality and are also used to control the session and provide diagnostic services. The feedback may include the number of packets sent, the number of packets lost, jitter, etc. This information can then be used by the source to modify its transmission so as to eliminate or at least reduce identified problems. The Session Description Protocol (SDP) is used to announce multimedia sessions. It specifies a short, structured textual file format for describing sessions, including the name and purpose of the session, the media, protocols, bandwidth requirements, timing and transport information. In particular, it provides the information needed to join and thus receive a multimedia session including streaming media sessions. SDP was developed by the Multiparty Multimedia Session Control (MMSC) working group of the IETF, and is found at RFC 2327.
The Real-Time Streaming Protocol (RTSP) is an application-level protocol for use in controlling streaming sessions. It typically works on top of RTP to both control and deliver real-time content. RTSP provides receivers of streams with “VCR-style” control functionality, such as pause, fast forward, reverse, etc. It is set forth at RFC 2326.
Allocation of Network Resources
Computer networks include numerous services and resources for use in forwarding network traffic, e.g., packets and frames, throughout the network. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, etc., offer unique speed and bandwidth capabilities. Particular intermediate devices also include specific resources or services, such as priority queues, filter settings, queue selection strategies, congestion control algorithms, etc. Depending on the selection or allocation of such resources or services, network traffic can be forwarded at different speeds or rates. To take advantage of these services and resources, individual frames or packets can be marked so that intermediate devices will treat them in a predetermined manner.
More specifically, the Institute of Electrical and Electronics Engineers (IEEE), in an appendix (802.1p) to the 802.1D bridge specification standard, describes additional information that can be loaded into the MAC header of Data Link Layer frames. FIG. 1A is a partial block diagram of a Data Link frame 100 which includes a MAC destination address (DA) field 102, a MAC source address (SA) field 104 and a data field 106. In accordance with the 802.1p standard, a user_priority field 108, among others, is inserted after the MAC SA field 104. The user_priority field 108 may be loaded with a predetermined value (e.g., 0-7) that is associated with a particular treatment. Possible treatments include background, best effort, excellent effort, etc. Network devices examine the user_priority field 108 of received frames 100 and apply the corresponding treatment to the frames. For example, an intermediate device may have a plurality of transmission priority queues per port, and may assign frames to different queues of a destination port on the basis of the frame's user priority value.
FIG. 1B is a partial block diagram of a Network Layer packet 120 corresponding to the Internet Protocol (IP), such as IPv4. Packet 120 includes a one octet differentiated services (DS) field 122 that can be loaded with a differentiated services codepoint (DSCP) value. Currently, DSCP values are 6-bits, leaving 2-bits of the DS field 122 unused. Packet 120 further includes a protocol field 124, an IP source address (SA) field 126, an IP destination address (DA) field 128 and a data field 130. The ToS field 122 was intended to be used to specify a particular service to be applied to the packet 120, but it is rarely used. The protocol field 124 is used to identify the next higher protocol that is to receive the packet. Version 6 of the Internet Protocol (IPv6) similarly includes a DS field, formerly known as the traffic class field.
Layer 3 devices that are DS compliant apply a particular per-hop forwarding behavior to packets based on the contents of their DS fields 122. Examples of per-hop forwarding behaviors include expedited forwarding and assured forwarding. By setting the DS field 122 with the DSCP value associated with the expedited forwarding PHB, the packet is forwarded with minimal delay or loss. By setting the DS field 122 with the DSCP value associated with the assured forwarding PHB, the packet receives better forwarding reliability than the traditional best efforts service. DS-compliant nodes typically establish special queues and/or employ queue selection strategies, such as Random Early Detection (RED), Random Early Detection with In and Out (RIO), etc., to achieve the forwarding requirements of the various PHBs.
The DS field 122 is typically loaded by DS compliant intermediate devices located at the border of a DS domain, which is a set of DS compliant intermediate devices under common network administration. Thereafter, interior DS compliant devices along the path examine the DS field 122 of received packets and apply the corresponding forwarding behavior to them.
FIG. 1C is a partial block diagram of a Transport Layer packet 150. In the TCP/IP Reference Model, the transport layer corresponds to the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The transport layer packet 150 preferably includes a source port field 152, a destination port field 154 and a data field 156, among others. Fields 152 and 154 are preferably loaded with the predefined or dynamically agreed-upon TCP or UDP port numbers being utilized by the corresponding network entities. A TCP or UDP packet 150 is typically encapsulated within an IP packet 120 by placing it in the data portion 130 of the IP packet 120. The IP packet 120, in turn, is encapsulated in the data portion 106 of a Data Link frame 100 for transmission across a computer link.
The Resource Reservation Protocol
As set forth above, to support streaming multimedia applications, the corresponding content must typically be delivered within specific, fixed time constraints and without jitter. Although many computer networks have the resources and services to meet the delivery requirements of streaming multimedia, these resources and services must be allocated, preferably in advance, to the correct network traffic. The Resource reSerVation Protocol (RSVP), which is set forth at RFC 2205, was developed so that entities (typically referred to as receivers) could reserve bandwidth within their computer networks to receive a desired traffic flow from one or more sourcing entities. Pursuant to RSVP, sources send RSVP Path messages identifying themselves and indicating the bandwidth needed to receive their programming or content. If a receiver is interested in the programming or content offered by a particular source, it responds with a RSVP Reservation (Resv) message, which travels hop-by-hop back to the source. At each hop, the corresponding intermediate device establishes a session for the receiver and sets aside the requested bandwidth for the desired traffic flow. With RSVP, traffic corresponding to streaming multimedia content can be accorded the resources and services it needs to ensure timely, jitter-free delivery.
Many network servers, including multimedia servers, however, do not include RSVP facilities. As a result, the bandwidth needed to support the content residing on these servers cannot be reserved in the computer networks which connect these servers to potential receivers. The quality of the presentations of this content may thus be substantially degraded.